[core] Move arguments with deleted copy ctor in TClingCallFunc #17030
Conversation
hahnjo
requested review from
bellenot,
jblomer,
dpiparo and
pcanal
as code owners
Test Results 18 files 18 suites 4d 3h 8m 23s ⏱️ Results for commit 5ba7196. ♻️ This comment has been updated with latest results. |
hahnjo
force-pushed
the
callfunc-move
branch
2 times, most recently
from
6adfb63
to
c123eea
Compare
hahnjo
changed the title
If a type is passed by value but cannot be copy-constructed, instead move the argument. This is important to make std::unique_ptr interfaces work from Python code. Note that there are corner cases where checking for a deleted copy constructor is not sufficient; for example the STL always declares a copy constructor for std::vector<std::unique_ptr<T>> which fails to instantiate if T is only moveable. Closes root-project#14425 Co-authored-by: Vincenzo Eduardo Padulano <[email protected]>
Co-authored-by: Vassil Vassilev <[email protected]>
hahnjo
force-pushed
the
callfunc-move
branch
from
c123eea
to
5ba7196
Compare
|
|
||
| for (auto *Ctor : RD->ctors()) { | ||
| if (Ctor->isCopyConstructor()) { | ||
| return Ctor->isDeleted(); |
There was a problem hiding this comment.
Should we also return true is the constructor is private or protected? (Since it has essentially the same effect)
There was a problem hiding this comment.
I would argue that no because it may be unexpected for the user that TClingCallFunc moves its objects when they "forget" to make their copy constructor public...
There was a problem hiding this comment.
it seems github or I did not publish the following comment/reply:
Well I am still confused. It seems that we now get different behavior whether the user 'deletes' the copy constructor in pre-C++11 ways or post=C++1 ways:
class OldStyle {
OldStyle(const OldStyle&); // Intentionally private and not implemented.
};
class NewStyle {
NewStyle(const NewStyle&) = delete;
};
Making a copy constructor private is an explicit operation so I don't think consider the case '"forget" to make public' as a major concern.
So my question is why would the user would 'expects' when "TClingCallFunc to move its objects when the copy constructor is deleted" but not when the copy constructor is private. What difference is semantic do you see?
There was a problem hiding this comment.
We cannot disambiguate "Intentionally private and not implemented" and forgotten, whereas delete is explicit. Users have to update their code to use C++11.
There was a problem hiding this comment.
and forgotten
How can it be 'forgotten' since making it private requires intentional typing?
There was a problem hiding this comment.
Well we could check if there is a copy constructor that is private I think. The question is what's the 'right' behavior in this case...
If a type is passed by value but cannot be copy-constructed, instead move the argument. This is important to make
std::unique_ptrinterfaces work from Python code. Note that there are corner cases where checking for a deleted copy constructor is not sufficient; for example the STL always declares a copy constructor forstd::vector<std::unique_ptr<T>>which fails to instantiate if
Tis only moveable.Closes #14425, alternative to #14426